The present invention relates generally to the management of data across a domain, an in particular to providing a common view and access point for customer information across multiple disparate data sources.
As an ever increasing number of services is being offered by various network providers, there is a corresponding increase in the number of systems, devices, applications, and components that utilize and store data for customers. While some of these data sources contain related data that can be easily aggregated or combined into a common schema, there are many sources that contain data that is considered to be substantially unrelated, or not easily aggregated, such that the data is not typically able to be accessed in a common fashion or point of entry. Further, companies may not wish to spend the time and money to generate common schemas or data repositories that are used across an entire domain.
For example, a telecommunications service provider typically maintains a large set of different repositories that each contain certain information about customers of that provider. FIG. 1 illustrates an example of an architecture 100 for such a provider. It can be seen that a number of systems and components reside behind the network and gateway layer 102, such as may include Business Support Systems (BSS) 104, a Service Delivery Platform (SDP) 106, Operational Support Systems (OSS) 108, and various other third party content and services 110. Each of these systems typically includes at least one repository containing a specific type of information, which generally is not substantially related or available to information in the repositories of the other systems.
For example, a BSS repository can store customer information from a service provider point of view, such as customer address information, customer billing information, products purchased by the customer, and campaigns to which a customer has responded. A BSS repository also can include subscription information for a customer, such as information for any voice, wireless, or roaming plan, as well as number of minutes purchased per month, etc. Such information is treated as product information from a BSS point of view, and the BSS repository also will include information as to whether a particular customer is subscribing to that product. If, for example, a customer subscribing to a new subscription is entitled to a new phone, that information typically will be maintained in the BSS repository. A BSS repository also typically is used to maintain trouble tickets, such as information regarding problems with service or failure to receive a form, as well as maintaining security credentials.
An OSS repository, on the other hand, is used for monitoring and administration of the system or other OSS operations such as charging/rating and activation provisioning. An OSS repository can also contain subscriber information such as information for the current and active bill for a customer, an inventory of assets associated with a customer, types of products or services provided to a customer, etc. A repository at the network level might include current network information for a customer, such as whether the customer is logged onto the network, a location of the customer on the network, whether a customer device is active, etc.
A service resource such as an SDP repository stores subscription information for a customer that is useful in running software services that are exposed to the customer, such as whether a particular customer has requested to receive news updates, and if so, also stores preference information such as which types of news the customer wishes to receive, e.g., international news or news related to a specific topic, as well as a channel in which to receive the news (e.g., SMS or MMS) and format information for the news (e.g., background color and font size). The SDP repository also can include information such as an identity for each customer, credentials, customer availability, etc.
There is other information that a telecommunications service provider may wish to combine with the SDP information. For example, a provider typically has to manage runtime information, such as presence and location information for a user on the network or other details related to the network activities, connectivity, etc. In addition to the context of a well factored-out service layer, the provider also manages dynamic information coming from the network, such as IMS Home Subscriber Service (IMS HSS) and Home Location Register (HLR) information. It can be desirable for all this information to be available to various services and applications.
Certain information overlaps or is related to other information stored for different services or in different repositories. Unfortunately, it is not practical for most entities to rewrite the schemas or redesign all the systems and services to use a common data model, single repository, single point of access, etc. As such, there typically is no way to treat the various repositories as a single data source that is readily available to applications, users, etc.
Certain approaches utilize a common database for all information related to principals such as subscribers. An exemplary architecture 200 for such an approach is shown in FIG. 2. In this example, data hubs 202 are used that are based on a common model, such as a customer data model or TMF (Telemanagement Forum) Shared Information/Data (SID) model. A problem with such an approach is that the common data model does not allow a system such as a BSS system to share data with the execution environment, which can include Home Subscriber Server (HSS) information, service specific data, presence information, etc., as the data is still maintained in silos at that level.
Further, a model such as that shown in FIG. 2 does not provide for identity management across the various systems (i.e., the possibility to associate credential, single sign-on, map/associate multiple identities to a same principal, anonymize some identities or federate the identities and repositories across multiple service providers/actors), and does not provide the tools needed to manage the identity of customers across the network, such as when a customer accesses a new service on the network or accesses the network using a new device. Further, functionality such as single sign-on and identity federation is not provided at the level of the customer data hub(s).